Do you already know how to run a Linux command (like ls) on the Android filesystem plugged into USB?

[Arlen Holder]

Do you already know how to run a Linux command (like ls) on the Android
filesystem plugged into USB?

The problem set and the current workarounds are already stated here, for
Windows, but the situation is exactly the same for Ubuntu.
From the desktop OS:
*How can we open a Linux command line on the Android filesystem?*
<https://groups.google.com/forum/#!topic/comp.mobile.android/vmWWLzPHKt0>

The question for this ng is how to run a command from Ubuntu 18.04 on the
Android file system plugged into the desktop USB port as an MTP device?

[Arlen Holder]

On Fri, 12 Oct 2018 15:43:51 -0000 (UTC), Arlen Holder wrote:

> The question for this ng is how to run a command from Ubuntu 18.04 on the
> Android file system plugged into the desktop USB port as an MTP device?

Drat.

Please ignore this thread as that post was created yesterday and was,
apparently, still in my drafts folder, which must have been accidentally
sent today when I hit "send all" on another thread elsewhere.

I had already solved the problem on Linux (where "Ubuntu just works").
Dualbooting to Ubuntu where the command line works fine on
the Android filesystem from Linux - but not from Windows:
<http://www.bild.me/bild.php?file=6181360dir01.jpg>

Sorry for the thread - where all I want - in the end - is for Windows to
run a DOS command like Linux does, on the Android file system over USB.
<http://www.bild.me/bild.php?file=9648761dir.jpg>

[Wildman]

I would either browse to the mount point using Nautilus
and open a terminal in that directory via context menu
or just open the terminal and change to the mount point
using the cd command. From there run the command(s).

--
<Wildman> GNU/Linux user #557453
The cow died so I don't need your bull!

[Arlen Holder]

On Fri, 12 Oct 2018 11:04:24 -0500, Wildman wrote:

> I would either browse to the mount point using Nautilus
> and open a terminal in that directory via context menu
> or just open the terminal and change to the mount point
> using the cd command. From there run the command(s).

Thanks. That post was written yesterday when I didn't have it tested, where
it works fine.

The Linux question is what "magic" is on Ubuntu that isn't on Windows that
allows this to work with dual-boot Ubuntu 18.04 but not Windows 10?

[Dan Purgert]

Or just use mc :)

Cue 90 billion posts about how we're not adults and don't know the utter
genius of ... whatever... though.


--
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5 4AEE 8E11 DDF3 1279 A281

[ray carter]

The 'magic' is that - on linux, everything is a file.

[Paul]

The same approach has been used in Linux (and Unix) a
number of times.

A new thing is exposed as a command-line-only feature first.

You cannot see the files initially in a file manager.
We used to work with floppy drives with MTOOLS, and
there was a utility for working with Mac HFS which
were like this. Today, mounting a floppy is transparent
(and visible in your file manager), as is the Mac stuff.

http://manpages.ubuntu.com/manpages/trusty/man1/mtp-tools.1.html

The other way is with MTPFS, which aligns with your
statement about "magic". In the fullness of time, indeed,
everything is a file.

https://wiki.archlinux.org/index.php/Media_Transfer_Protocol

And the Linux way, is to fake any necessary parameters,
so that stat() always returns a sensible result. NTFS
doesn't have inodes for example. If you mount NTFS and
list inodes, you receive unique numbers for your trouble.
What are those numbers ? They're the filenum# field from
NTFS, stuffed in as an inode number. This solves the
problem of providing a unique number for the inode number,
even though there is no intention of actually using
inode operations (as NTFS doesn't have inodes).

I can't imagine how they would have back-filled MTP while
doing MTPFS :-) Think of the stuff that would be missing.
Must have been a horror show.

Paul

[Arlen Holder]

On Fri, 12 Oct 2018 20:10:41 -0400, Paul wrote:

> The other way is with MTPFS, which aligns with your
> statement about "magic". In the fullness of time, indeed,
> everything is a file.

Hi Paul,

Thanks for those useful pointers for how MTP works on Ubuntu 18.04.

As you know, the technical solution I see is a very _hard_ question to
answer, which is why the many Windows (& a few Linux) trolls will have a
field day (since all they _can_ do, is troll).

I'm trying to move the technical ball forward, which isn't easy.

Hence, on this Linux thread, I will not respond to the worthless trolls
with the hope of alienating them - I will only respond to those intelligent
people who are purposefully helpful - where - for Linux - the trick is to
figure out what exactly makes it work for Linux (and then see if _that_ can
be implemented universally, on Windows).

To be clear, I read what was written prior, where the "magic" is supposed
to be that Linux treats the Android file system as a "file"; but I don't
comprehend that answer well enough to turn it into a solution on Windows.

Do you?
Without a solution, this will be just a worthless chit-chat thread.

This description of the difference between libmtp & libgphoto2 says the
same thing, which is that "the unix way" is that "everything is a file".
<http://libmtp.sourceforge.net>

But that doesn't, yet, help me implement a _solution_ to the problem.

Looking at your 1st URL to see where we can come up with a solution...
<http://manpages.ubuntu.com/manpages/trusty/man1/mtp-tools.1.html>
That seems to make use of the libmtp package which is used by:
o MTPfs FUSE filesystem <https://www.adebenham.com/mtpfs/>
o Android libmtp client <https://github.com/hanwen/go-mtpfs>
o MTP support on KDE <https://cgit.kde.org/kio-mtp.git>
o MTPdude file transfer utility <http://mtpdude.sourceforge.net>
o The GNOME Virtual file system <https://en.wikipedia.org/wiki/GVfs>
o XNJB Mac OS X GUI <http://www.wentnet.com/projects/xnjb/>
o GTK+ music manager <http://gnomad2.sourceforge.net>
o Amarok KDE music player <https://amarok.kde.org>
o Rhythmbox Gnome music player <https://wiki.gnome.org/Apps/Rhythmbox>
o MTPSync file synchronizer <https://www.adebenham.com/mtpsync/>
o JMTP FS <https://github.com/JasonFerrara/jmtpfs>

This is good information, Paul, because it tells us that "libmtp" is key.
It also tells us that MTPFS uses "libtmp", so again, "libtmp" seems key.

Looking at your second URL:
<https://wiki.archlinux.org/index.php/Media_Transfer_Protocol>
We find there are a few Android related "FUSE" filesystems for Linux:
o fb-adb Android Linux shell <https://github.com/facebook/fb-adb>
o gphotofs Camera Linux mount <http://www.gphoto.org/proj/gphotofs/>

But mostly, if we want an actual solution (rather than just idle chitchat),
I need to focus on one of these three:
o libmtp library MTP implementation <http://libmtp.sourceforge.net>
o AFT MTP client <https://whoozle.github.io/android-file-transfer-linux/>
o go-mtpfs MTP FUSE filesystem <https://github.com/hanwen/go-mtpfs>

Given that information above, I think I'll first approach trying to get one
of those three solutions to work on Windows, if that's even possible.

Thanks for your insight in this difficult problem that, to my knowledge,
has not yet been solved universally on Windows over USB (but which does
have proprietary solutions so we _know_ it's possible).

Also, it has always been possible to map Android as a drive using a
*server* on Android (such as an FTP server, WebDav server, HTTP server, and
even, but only if you're rooted, an SMB server):
How to Map or Mount Android as a Drive on Windows
<https://www.guidingtech.com/39472/map-android-drive-windows/>
<https://play.google.com/store/apps/details?id=com.theolivetree.webdavserver>

The goal was never to add a server to the Android system; so these
solutions, while they work, are out of scope. The solution you pointed to,
if it works on Windows, is the correct scope, namely:
o libmtp
o aftmtp
o go-mtp fs

[Jasen Betts]

It's much deeper than that. the read() and write() system
calls work on pipes, tcp sockets, character devices (tty, pty,
serial port, printer port) block devices (tape, disk, MMC),
system memory (via /dev/mem), and regular files on mounted
filesystems.

Every _thing_ is a file.

On windows It's not like that, the comsole, and serial ports, are files;
but tcp sockets aren't so different calls are needed to handle them,
select works on sockets but something different is needed for serial ports
etc...

https://en.wikipedia.org/wiki/Everything_is_a_file

mtools (for reading FAT devices) wirked by opening the device
(or a image file) like a file and modifying its content in the
normal way. the main advantage of mtools was that you didn't
need to mount disk to access the content or remember to unmount
it, linux has has FAT mount/read/write capability since "forever"
(it was there in kernal 0.95)

--
Notsodium is mined on the banks of denial.

[Arlen Holder]

On Sat, 13 Oct 2018 01:53:21 -0000 (UTC), Jasen Betts wrote:

> On windows It's not like that, the comsole, and serial ports, are files;
> but tcp sockets aren't so different calls are needed to handle them,
> select works on sockets but something different is needed for serial ports
> etc...

I made some progress in the last half hour that I wish to report, which is
that, at least for the _external_ sdcard, I've solved the problem, I think,
of running a DOS command on the Android filesystem mounted as a drive
letter, over USB without _anything_ being installed on Android.

I tested out a crippleware v2.10 trial version of MTPDrive on Windows.
<http://mtpdrive.com/download.html>
Where this is what I entered into my log file just now by way of testing.
============================================================================
1. Install MTP Drive version 2.10 crippleware on Windows
<http://mtpdrive.com/download.html>
2. Create a shortcut to C:\app\network\mtpdrive\MTPdrive.exe
3. Connect the Android device over USB & run that MTPdrive.exe shortcut
4. Press the MTPDrive GUI "Map" button to map the phone to a named drive
5. This mounts the Android external sdcard as a named drive, e.g., (M:)
6. Right click to "Open Command Window Here" to run a DOS command
7. Run the desired DOS command on that now-mounted Android filesystem
dir /s/a/l/on/b *.apk

Voila!
<http://www.bild.me/bild.php?file=1853998dir02.jpg>

For another inventory of _every_ file on the external sdcard:
A. Connect the Android device to the USB port of the Windows PC
B. Run the MTPDrive GUI at C:\app\network\mtpdrive\MTPdrive.exe
C. Press the MTPDrive "Settings" button & then go to the "Settings" tab
D. Press the "Dump device data to a file" button > C:\tmp\WPD.log

The bottom portion of that log file will contain a list of every file found.
\SD card\1data\software\apk\lgapps\Calculator-com.google.android.calculator-75013172-v7.5 (213680574).apk
\SD card\1data\software\apk\lgapps\Chrome-com.android.chrome-349710002-v69.0.3497.100.apk
\SD card\1data\software\apk\lgapps\Cloud Print-com.google.android.apps.cloudprint-140-v1.40.apk
\SD card\1data\software\apk\lgapps\Docs-com.google.android.apps.docs.editors.docs-183920235-v1.18.392.02.35.apk
\SD card\1data\software\apk\lgapps\Drive-com.google.android.apps.docs-183920235-v2.18.392.02.35.apk
\SD card\1data\software\apk\lgapps\Duo-com.google.android.apps.tachyon-2602856-v39.1.213443905.DR39_RC19.apk
\SD card\1data\software\apk\lgapps\Facebook App Manager-com.facebook.appmanager-46985667-v18.4.apk
\SD card\1data\software\apk\lgapps\Facebook-com.facebook.katana-1-vstub.apk
\SD card\1data\software\apk\lgapps\Gmail-com.google.android.gm-60804175-v8.9.23.215020111.release.apk
etc.

The good news:
o This crippleware allows us to map the external sdcard to a Windows drive letter.
The bad news:
o It only seems to work for the _external_ sdcard (not the internal sdcard!)
============================================================================
In summary, the good news is that it's possible to run a DOS command
on the Android file system; but the bad news is that the solution above,
while easy, and free, is restricted to the external sdcard, AFAIK at this time.

I'll dig further into Paul's suggested Urls, particularly those on libmtp
for a more general solution that mounts the _entire_ Android filesystem
as a drive letter on Windows.

[Arlen Holder]

On Sat, 13 Oct 2018 03:34:20 -0000 (UTC), Arlen Holder wrote:

> In summary, the good news is that it's possible to run a DOS command
> on the Android file system; but the bad news is that the solution above,
> while easy, and free, is restricted to the external sdcard, AFAIK at this time.

By way of further update, the good news is that it worked
on the external sdcard files.

The bad news is that, while a DOS "dir" command works fine, a DOS "copy"
is artificially limited by the crippleware to 30 files per session.
<http://www.bild.me/bild.php?file=8315262dir03.jpg>

Obviously I'll continue to seek a general solution; but
this is at least proof of concept that mounting the Android
file system on Windows as a drive letter so that DOS commands
can run on that filesystem "can" work as well as it does on Linux.

We just have to figure out how.

[Arlen Holder]

On Sat, 13 Oct 2018 04:44:13 -0000 (UTC), Arlen Holder wrote:

> We just have to figure out how.

While I solved the problem (maybe even the first to do it, AFAIK, on the
Windows ng), I went through a bunch of failures, one of which was the goal
of getting libmtp to work on Windows.

Interestingly, there is a Windows port of the Linux libmtp:
<https://sourceforge.net/projects/libmtp/>
Which contains a score of binaries:
<https://iweb.dl.sourceforge.net/project/libmtp/libmtp-win32/0.3.5-win32-1/libmtp-0.3.5-win32-bin.zip>

But I just didn't know enough, technically, to make it do anything useful.

Hence, the final "solution" for the tribal archives is written up here
(sans any mention of libmtp solutions)
<https://groups.google.com/d/msg/microsoft.public.windowsxp.general/6UdMAFVkv3s/wuxFT8T3AgAJ>

[Carlos E.R.]

On 13/10/2018 03.52, Arlen Holder wrote:
> On Fri, 12 Oct 2018 20:10:41 -0400, Paul wrote:
>
>> The other way is with MTPFS, which aligns with your
>> statement about "magic". In the fullness of time, indeed,
>> everything is a file.
>
> Hi Paul,
>
> Thanks for those useful pointers for how MTP works on Ubuntu 18.04.
>
> As you know, the technical solution I see is a very _hard_ question to
> answer, which is why the many Windows (& a few Linux) trolls will have a
> field day (since all they _can_ do, is troll).
>
> I'm trying to move the technical ball forward, which isn't easy.
>
> Hence, on this Linux thread, I will not respond to the worthless trolls
> with the hope of alienating them - I will only respond to those intelligent
> people who are purposefully helpful - where - for Linux - the trick is to
> figure out what exactly makes it work for Linux (and then see if _that_ can
> be implemented universally, on Windows).
>
> To be clear, I read what was written prior, where the "magic" is supposed
> to be that Linux treats the Android file system as a "file"; but I don't
> comprehend that answer well enough to turn it into a solution on Windows.
>
> Do you?
> Without a solution, this will be just a worthless chit-chat thread.

Is this going to be another of your eternal threads spiced with insults
to those you do not like what they say?

There is no magic.

It is simply that somebody took the time and pain to implement an MTP
file layer, so that ANY Linux tool designed to do standard operations on
files work on what it appears to it to be just another directory, which
happens to be on an Android gadget connected via cable.

Whereas those people at Windows only designed a file browser to do some
file operations, in a way that no other tool can use it, being
"private". Any other tool (another file browser, a photo management tool
perhaps) has to design its own layer again, or perhaps, pay the first
people to use the API and libraries.

Unless it is Microsoft who does the work and exposes the layer, but only
those tools that explicitly know how to use that precise layer will use
it...


Linux has been designed from the start with a thing called VFS. All
filesystems, real or emulated, are handled via this layer. Android MTP,
is just another one.

<https://en.wikipedia.org/wiki/Virtual_file_system>

A Virtual File System (VFS) or virtual filesystem switch is an
abstraction layer on top of a more concrete file system. The purpose of
a VFS is to allow client applications to access different types of
concrete file systems in a uniform way. A VFS can, for example, be used
to access local and network storage devices transparently without the
client application noticing the difference. It can be used to bridge the
differences in Windows, classic Mac OS/macOS and Unix filesystems, so
that applications can access files on local file systems of those types
without having to know what type of file system they are accessing.

A VFS specifies an interface (or a "contract") between the kernel and a
concrete file system. Therefore, it is easy to add support for new file
system types to the kernel simply by fulfilling the contract. The terms
of the contract might change incompatibly from release to release, which
would require that concrete file system support be recompiled, and
possibly modified before recompilation, to allow it to work with a new
release of the operating system; or the supplier of the operating system
might make only backward-compatible changes to the contract, so that
concrete file system support built for a given release of the operating
system would work with future versions of the operating system.

--
Cheers, Carlos.

[Dan Purgert]

Carlos E.R. wrote:
> [...]

> Is this going to be another of your eternal threads spiced with insults
> to those you do not like what they say?

Yes. :)

> [...]

> Linux has been designed from the start with a thing called VFS. All
> filesystems, real or emulated, are handled via this layer. Android MTP,
> is just another one.

And now 'fuse' finally makes sense.

[Arlen Holder]

On Mon, 15 Oct 2018 04:42:14 +0200, Carlos E.R. wrote:

> Is this going to be another of your eternal threads spiced with insults
> to those you do not like what they say?

You clearly misunderstand the basic concept of a funnel & of a mirror.

> It is simply that somebody took the time and pain to implement an MTP
> file layer, so that ANY Linux tool designed to do standard operations on
> files work on what it appears to it to be just another directory, which
> happens to be on an Android gadget connected via cable.

I clearly don't yet understand the basic concept of "everything is a file".

[Arlen Holder]

On Mon, 15 Oct 2018 09:53:11 -0000 (UTC), Dan Purgert wrote:

> And now 'fuse' finally makes sense.

I ran a score of experiments, where every test on Linux worked fine,
proving that a universal solution already exists for Linux users:
<http://www.bild.me/bild.php?file=6181360dir01.jpg>

On Windows, a solution exists, but it's not universal in that it's
proprietary in that it involves non-universally applicable crippleware:
<http://www.bild.me/bild.php?file=9648761dir.jpg>
<http://www.bild.me/bild.php?file=6181360dir01.jpg>
<http://www.bild.me/bild.php?file=1853998dir02.jpg>
<http://www.bild.me/bild.php?file=8315262dir03.jpg>
<http://www.bild.me/bild.php?file=8605173dir05.jpg>
<http://www.bild.me/bild.php?file=7687244dir06.jpg>
<http://www.bild.me/bild.php?file=7075400dir07.jpg>
<http://www.bild.me/bild.php?file=3316456dir08.jpg>
<http://www.bild.me/bild.php?file=3168139ftpd.jpg>

At this point, since the one test worked perfectly for my needs, I have
shelved the noble attempt to outline a more universal solution for Windows
that solves all users' problem set, not just mine.

[Aragorn]

On Monday 15 October 2018 12:34, Arlen Holder conveyed the following to
alt.os.linux...

It actually goes deeper than that everything is a file. In the kernel
of UNIX operating systems, everything ─ and I do mean "everything" ─ is
a stream of bytes, and streams of bytes can therefore be regarded as
files for presentation to userspace.

Unlike in DOS ─ I'm not familiar enough with Microsoft Windows to know
how it is there ─ files are not terminated by an End-Of-File (EOF)
character. Instead, UNIX processes the stream of bytes until it
receives an End-Of-Transmission character (EOT) ─ commonly ^D (Ctrl+D).

The principle of everything being presentable to userspace as a file can
already be found again in how a UNIX operating system ─ and in this case
specifically, GNU/Linux ─ addresses storage devices.

For instance, the first detected SCSI/SAS/SATA/PATA hard disk in your
system is /dev/sda. That is a file. The first primary partition on
/dev/sda is /dev/sda1. That, too, is a file. You can even have named
pipes as filesystem objects. And as such, all of those things can be
manipulated in the same way as any other file can be manipulated. They
can be opened, and bytes can be read from them or written to them.

--
With respect,
= Aragorn =

[Arlen Holder]

On Fri, 12 Oct 2018 18:48:25 -0000 (UTC), Dan Purgert wrote:

> Cue 90 billion posts about how we're not adults and don't know the utter
> genius of ... whatever... though.

You clearly misunderstand the concept of a mirror used as a funnel.

[Dan Purgert]

Arlen Holder wrote:
> On Mon, 15 Oct 2018 04:42:14 +0200, Carlos E.R. wrote:

>> [...]

>> It is simply that somebody took the time and pain to implement an MTP
>> file layer, so that ANY Linux tool designed to do standard operations on
>> files work on what it appears to it to be just another directory, which
>> happens to be on an Android gadget connected via cable.
>
> I clearly don't yet understand the basic concept of "everything is a
> file".

The "MTP file Layer" is not the same thing as "everything is a file".

MTP File Layer -> Virtual File System that any other tool can interact
with (via the VFS "driver"), without needing to actually know how to
talk to what's at the other end. Same basic idea as the kernel (and
filesystems) acting as an intermediary between programs and the actual
underlying block device.

"Everything is a file" is the basic concept of UNIX and UNIX-Like
operating systems. You can interact with any _thing_ using basic "file"
operations. For example, if you had a printer capable of reading
postscript at /dev/prt (i.e. taking the postscript and converting it to
normal text).

cat toPrint.ps > /dev/prt

[Arlen Holder]

On Mon, 15 Oct 2018 12:45:53 +0200, Aragorn wrote:

> "everything" € is
> a stream of bytes, and streams of bytes can therefore be regarded as
> files for presentation to userspace.

Thank you for the clarification, where, the net result of a scores of
experiments was that, on Linux, "everything just works" in terms of
"running a command" directly on the Android filesystem.

On Windows, over Wi-Fi, it was always the case that:
- Android WebDav/HTTP/HTTPs servers worked just fine
- Android FTP/SSH servers worked fine (for the most part)
- Android SMB/CIFs/Samba servers universally fail (unless rooted)
etc.

And, to the original point, on Windows, over USB:
- The only solution that worked was the MTPDrive crippleware

That is, while "general solutions" abound for Linux, no "general solution"
was found, for Windows. (yet)

As a general solution is _always_ the goal, even though I/we easily
succeeded in solving my original problem, I admit that I/we failed to find
the more general Windows/Android solution that solves everyone's problem.

[Dan Purgert]

Arlen Holder wrote:
> On Mon, 15 Oct 2018 12:45:53 +0200, Aragorn wrote:
>
>> "everything" is a stream of bytes, and streams of bytes can therefore
>> be regarded as files for presentation to userspace.
>

> That is, while "general solutions" abound for Linux, no "general solution"
> was found, for Windows. (yet)

"Format and install Linux" <-- the general solution to all problems in
Windows.

[Arlen Holder]

On Mon, 15 Oct 2018 11:14:40 -0000 (UTC), Dan Purgert wrote:

> "Format and install Linux" <-- the general solution to all problems in
> Windows.

Hi Dan Purgert,

Your humor, as always, is hilarious for children of the fifth grade
(hence, always useless in terms of providing any semblance of adult value).

This is my _last_ response in this thread to worthless trolls, Dan Purgert.

[Carlos E.R.]

There you go as usual.

Which is a pity, because he posted the correct answer to your question
in another post.

--
Cheers, Carlos.

[Carlos E.R.]

I did not say anything about that basic concept. Please read again my post.

--
Cheers, Carlos.

[Dan Purgert]

Carlos E.R. wrote:
> [...]

> Which is a pity, because he posted the correct answer to your question
> in another post.

To be fair, "just use Linux" is a fine solution, given

- Linux does what is wanted out of the box (or with an added package or
two)
- Windows support, even with additional packages, is spotty at best
- This is a linux newsgroup. (or at least "alt.os.linux" implies it's
for linux; maybe I'm wrong?)

[Wildman]

On Mon, 15 Oct 2018 13:15:34 +0000, Dan Purgert wrote:

> - This is a linux newsgroup. (or at least "alt.os.linux" implies it's
> for linux; maybe I'm wrong?)

It has been turned into a private blog.

[Dan Purgert]

Wildman wrote:
> On Mon, 15 Oct 2018 13:15:34 +0000, Dan Purgert wrote:
>
>> - This is a linux newsgroup. (or at least "alt.os.linux" implies it's
>> for linux; maybe I'm wrong?)
>
> It has been turned into a private blog.

Ugh :(

[Carlos E.R.]

On 15/10/2018 15.15, Dan Purgert wrote:
> Carlos E.R. wrote:
>> [...]
>> Which is a pity, because he posted the correct answer to your question
>> in another post.
>
> To be fair, "just use Linux" is a fine solution, given
>
> - Linux does what is wanted out of the box (or with an added package or
> two)
> - Windows support, even with additional packages, is spotty at best
> - This is a linux newsgroup. (or at least "alt.os.linux" implies it's
> for linux; maybe I'm wrong?)

Yes :-)

--
Cheers, Carlos.

[Arlen Holder]

On Fri, 12 Oct 2018 15:43:51 -0000 (UTC), Arlen Holder wrote:

> The question for this ng is how to run a command from Ubuntu 18.04 on the
> Android file system plugged into the desktop USB port as an MTP device?

Thanks for all the advice, where the main help came from Paul who advised
the LibMTP which, I still think, is the solution for Windows since LibMTP
seems to be the underlying code for Linux.

If you're interested, here is a summary of the *Windows* progress to date.

Please note that I _already_ have a solution, on Linux, and on Windows
using both USB & Wifi, where the goal was & is always a general solution
for everyone - not just for me.
o There are many freeeware solutions over WiFi on all platforms
o It's modern Android MTP over USB on Windows that has no general fix
(yet) (where LibMTP is likely that missing solution)
=============================================================
Here's a summary of the "general solution" status on Windows to date...
=============================================================
In the Windows ng, Frank Slootweg suggested "netdrive", located here:
<http://netdrive.net/download> (trialware, so it's not a general solution)
Just in case the old freeware existed, I downloaded the following versions:
o NetDrive 3.6.571 <http://netdrive.net/>
o NetDrive 3.5.434 <https://en.freedownloadmanager.org/Windows-PC/NetDrive.html>
o NetDrive 2.6.2 <https://filehippo.com/download_netdrive/64426/>
o NetDrive 2.6.16 build 962 <https://www.filehorse.com/download-netdrive/30799/download/>
o NetDrive 2.5.7 <https://netdrive.en.lo4d.com/>
o NetDrive 1.3.4 <https://filehippo.com/download_netdrive/15075/>
etc.

I have one key question for anyone on this ng who knows Windows well, which
is whether my "assumption" is accurate that we need to "mount" the Android
filesystem as a "removable drive" (i.e., with a "drive letter") in order to
be able to run any Windows command on that Android filesystem?

I seem to be able to run DOS commands on both these types of connections:
o USB + "removable drive" (to get a drive letter)
<http://www.bild.me/bild.php?file=1853998dir02.jpg>
o WiFi + "network location" + "removable drive" (to get a drive letter)
<http://www.bild.me/bild.php?file=6340420dir012.jpg>
o WiFi + "network location" + "net use" (to get a drive letter)
<http://www.bild.me/bild.php?file=8605173dir05.jpg>

Is that assumption of the intermediate "need" for a drive letter correct?
If so, here's a summary of where we stand based on that assumption...
(If not, please correct where I err.)

The "problem" is that when you connect over USB an Android 4.3+ device
(mine is a $130 64GB LG Stylo 3 Plus, running Nougat, Android 7.0) as MTP,
you can't run any Windows command on the Android file system, as evidenced
by this "dir" of APKs that had to be done after copying to Windows:
<http://www.bild.me/bild.php?file=9648761dir.jpg>

The best solution is to "mount" the Android filesystm as a "removable
drive" (i.e., it gets a drive letter) over USB, which I can easily do with
payware/crippleware, but which I'm trying to make into a general solution
that _everyone_ can do.
<http://www.bild.me/bild.php?file=8315262dir03.jpg>

*For a general solution, we need bona-fide non-crippled Windows freeware.*
o The goal is a _universal_ solution (which necessitates _freeware_);
o which enables _any Windows command_ to run on the Android filesys;
o which means (I think) it has to be "mounted" as a _removable drive_;
o (or, in other words, it has to have a "drive letter" when on USB);
o (although a Windows "network location" can also work when on WiFi);
o which both MTPDrive (over USB) & NetDrive (over WiFi) payware seem to do

Given:
o USB solutions are faster & generally simpler (no Android software)
MTPDrive: <http://www.bild.me/bild.php?file=1853998dir02.jpg>
Linux: <http://www.bild.me/bild.php?file=6181360dir01.jpg>
o WiFi solutions (which generally require a "server" running on Android).
WebDav: <http://www.bild.me/bild.php?file=8605173dir05.jpg>
FTP: <http://www.bild.me/bild.php?file=7687244dir06.jpg>

For USB:
The best solution is a freeware equivalent to the MTPDrive functionality
o LibMTP freeware may work if we can figure out how to make it work, while
<https://sourceforge.net/projects/libmtp/files/libmtp-win32/>
o MTPDrive crippleware works (crippled to 30 files per session), and,
<http://www.mtpdrive.com/download.html>
o Dual booting to Linux works (which natively uses, apparently, LibMTP).
<http://www.bild.me/bild.php?file=6181360dir01.jpg>

For WiFi:
If a server must be run on Android, Windows probably handles SMB best, but:
o SMB server (on Android) solutions are problematic for two reasons:
(a) No known Play/F-Droid SMB server works on TCP port 445 unrooted
(b) Port forwarding on Windows is required if a nonroot server is found.
<https://play.google.com/store/apps/details?id=com.icecoldapps.sambaserver>

Where these general-use servers don't require rooting or port forwarding,
& where Windows "network location" & "removable drive" features are used:
o WebDav
<https://play.google.com/store/apps/details?id=com.theolivetree.webdavserver>
network location: <http://www.bild.me/bild.php?file=8605173dir05.jpg>
o FTP
<https://play.google.com/store/apps/details?id=com.theolivetree.ftpserver>
<http://www.bild.me/bild.php?file=7075400dir07.jpg>
<http://www.bild.me/bild.php?file=4731516dir011.jpg>

For WiFi FTP, these are possible universal free drive-mapping solutions:
o FTPuse (freeware which I was not successful with in my recent tests)
<https://www.ferrobackup.com/map-ftp-as-disk.html>
FTP Server (free): <http://www.bild.me/bild.php?file=3316456dir08.jpg>
The Olive Tree: <http://www.bild.me/bild.php?file=7355568dir09.jpg>
Anonymous: <http://www.bild.me/bild.php?file=4223201dir010.jpg>
o DirectNet (freeware which I was successful with in my tests today)
<http://www.directnet-drive.net/>
<http://www.bild.me/bild.php?file=4731516dir011.jpg>
<http://www.bild.me/bild.php?file=6340420dir012.jpg
o SFTP Net Drive (free for personal use but I was not successful today)
<https://www.nsoftware.com/sftp/netdrive/> (it took a bogus name & email)
o NetDrive (trialware, untested because it's not a general solution)
<http://netdrive.net/>
o Web Drive (trialware, untested because it's not a general solution)
<https://webdrive.com/download/>

And where Linux solutions may work under some circumstances:
o Dual-boot to Linux works perfectly (which uses LibMTP natively)
<https://groups.google.com/d/msg/alt.os.linux/oOfdMLmJ-oQ/jh_1DwTOBgAJ>
o Termux (contains a mini Linux command environment)
<https://play.google.com/store/apps/details?id=com.termux>

As always, this effort is for everyone - so please improve where you can!

[Arlen Holder]

On Fri, 19 Oct 2018 23:42:21 -0000 (UTC), Arlen Holder wrote:

> If you're interested, here is a summary of the *Windows* progress to date.

If folks are interested, here's a summary I just wrote on inexplicable
issues with the WiFi Android FTP Server "network location" mapped to a
"drive letter" using three different types of freeware, some of which also
exist for Linux (e.g., FTPUse).

I will run some experiments of FTPUse below on Ubuntu 18.04, where I'm not
at all sure why FTPUse on Windows 10 failed in every test this week.
=========================

Here is my detailed response to Frank's purposefully helpful suggestions.

As I recall, FTUUse used to work for me on Windows with Android 4.4 (Galaxy
S3); but FTPUse no longer seems to work for me on my Android 7.0 LG phone -
but - I'm not too worried for two reasons:
a. I found a method that did work for me with FTP over Wi-Fi, and,
b. Even if I hadn't found that method that worked, USB is the main goal.

For this post, we aren't discussing USB.
For this post, we're only discussing WiFi.

And, for this post, we're not discussing any other server other than FTP.
(For example, we're not discussing WebDAV, which always worked just fine.)

What we want, for this post, is a *drive letter*.
We never had problems with a "network location".

What else, we want for this post, is a *universal solution*.
That means anyone can do it (not just you and me, Frank).

In general, that means freeware.
I think we have that solution below using DND freeware.
o DirectNet-Drive created a drive letter of a WiFi FTP network location

But I acknowledge that _other_ freeware should have worked for me.
o FTPUse should have worked (and I think it did work, in the past, for me)
<https://www.ferrobackup.com/download/FtpUseInst.exe>
o SFTP Net Drive should have worked (but it also failed for me)

<https://www.nsoftware.com/sftp/netdrive/> (it took a bogus name & email)

What worked for me the very first time, was this combination:
1. Android freeware FTP Server:
<https://play.google.com/store/apps/details?id=com.theolivetree.ftpserver>
2. Windows freeware map of "network location" to a "removable drive":
<http://www.directnet-drive.net/>

Here is a screenshot of the FTP WiFi connection as a drive letter (R:)
<http://www.bild.me/bild.php?file=4731516dir011.jpg>
And here is a screenshot showing that I can run DOS commands on Android:
<http://www.bild.me/bild.php?file=6340420dir012.jpg
Where both those connections are made using the Olive Tree FTP server
on my Windows 10 desktop connected to Android 7.0 Nougat.

For whatever reasons, on my Windows 10 system, FTPUse failed under exactly
the same circumstances (both as a password user & as anonymous):

FTPUse failing with the "Olive Tree" FTP server as user "francis":
<http://www.bild.me/bild.php?file=7355568dir09.jpg>
FTPUse failing under the same FTP server as user "anonymous":
<http://www.bild.me/bild.php?file=4223201dir010.jpg>

As you know, FTPUse also failed when I used F-Droid "FTP Server (Free)":
<https://f-droid.org/en/packages/be.ppareit.swiftp_free/>
Where these screenshots are from a few days ago when I ran those tests:

<http://www.bild.me/bild.php?file=7687244dir06.jpg>
<http://www.bild.me/bild.php?file=7075400dir07.jpg>
<http://www.bild.me/bild.php?file=3316456dir08.jpg>

SFTPNetDrive freeware also failed today with the "Olive Tree" server where
SFTP NetDrive simply failed to connect whether using user "francis" or
"anonymous".

In summary, I was never worried about FTPUse not working on Windows 10 for
me since I prefer USB and since I found (by trial and error) an WiFi FTP
solution that works as a general freeware solution for everyone, which is
"DirectNet-Drive".

If we still wish to move the ball forward, we should ask another Windows 10
user to see if FTPUse or SFTP NetDrive works for _them_.

All I can tell people here is that my empirical results are the following:
o Using multiple FTP servers on non-root Android 7.0 Nougat...
o DirectNetDrive Windows 10 network-location-to-drive-letter worked!
o But both FTPUse & SFTP NetDrive failed (under the same conditions).

Why?
I don't know why.

If another Windows 10 user can test either of those two failed solutions,
we will get a better idea if it's Windows 10, or if it's just me.

--
As always, the Usenet goal is for all to help everyone with their efforts.

[Arlen Holder]

On Sat, 20 Oct 2018 00:20:14 -0000 (UTC), Arlen Holder wrote:

> If another Windows 10 user can test either of those two failed solutions,
> we will get a better idea if it's Windows 10, or if it's just me.

WiFi:
Here is the detailed thread showing noobs how to use WiFi FTP to map network
locations to named removable drives on Windows if the users don't already
know how from using Linux.
<https://groups.google.com/forum/#!topic/comp.mobile.android/IswZ5yEcpYA>
Note that there's a minor typo in one command which won't faze Linux users:
ftp> open 192.168.1.6 2221 (your IP address & port may well differ)

USB:
To answer Paul's question about USB libMTP documentation, there's a readme:
C:\software\network\mtp\libmtp\README.windows.txt
Which says, summarized:
LibMTP depends on LibUSB and libiconv.
o LibUSB Win32 - http://libusb-win32.sourceforge.net/
o LibIconv - http://gnuwin32.sourceforge.net/packages/libiconv.htm
LibMTP takes advantage of the LibUSB-Win32 Device Driver package.

These appear to be the directions to get Android to work over USB with LibMTP.

1. Download the latest device driver binary package (libusb-win32-device-bin-x.x.x.x.tar.gz) from http://sourceforge.net/project/showfiles.php?group_id=78138
2. Upon extraction, plug in your Android device and run bin/inf-wizard.exe.
Select your device and save the resulting inf file in the project root directory.
3. Copy the files "bin/libusb0.dll" and "libusb0.sys" for 32-bit operating systems.
Copy the files "libusb0_x64.dll" and "libusb0_x64.sys" for 64-bit operating systems.
4. Goto Start -> Run, type "devmgmt.msc" and press "ok".
5. Select your Android device from the list and click Action -> Update Driver,
Choose "No, not this time" if prompted to connect to microsoft.
6. Choose "Install from a list or specific location".
7. Choose "Don't search, I will choose the driver to install
8. Click the "Have Disk..." button in the bottom right corner of the prompt
9. Browse to your .inf file and select it. Press Ok
10. The name of your Android device should appear in the prompt,
click it and click "Next>" (Ignore any prompts about Driver Signing,
continuing installation of the selected driver).
11. Click finish to end the driver install process.

If needed, to roll back to the original Android USB driver:
1. Goto Start -> Run, type "devmgmt.msc" and press "ok".
2. Select your Android device, right click on it and click "Properties"
3. Go to the "Driver" pane and select "Roll Back Driver".

I'll run as many of those steps as I can, but I'm not a coder.
I'm an empirical tester. I run things until they work.

If I'm successful, this will be a first (to my knowledge) where almost
nobody knows how to do this, AFAIK, and where the power is immense
in that we can connect Android as a drive letter over USB using only
Windows freeware so that _all_ Windows commands run on the Android
filesystem.

[Arlen Holder]

On Sat, 20 Oct 2018 03:15:47 -0000 (UTC), Arlen Holder wrote:

> If I'm successful, this will be a first (to my knowledge) where almost
> nobody knows how to do this, AFAIK, and where the power is immense
> in that we can connect Android as a drive letter over USB using only
> Windows freeware so that _all_ Windows commands run on the Android
> filesystem.

The goal is for _everyone_ to be able to run any Windows command on Android
over USB, which necessitates a working freeware solution (where we already
have payware solutions that work just fine) - and where simply dual booting
to Linux works fine to run Linux commands on the Android phone over USB.

It's Windows that has the lack of a general solution for everyone.
To that end I (maybe) broke new ground by finally getting libMTP to work.
However, it may be, I think, LibMTP may have been a red herring all along.

Yesterday I installed Zadig & libusbK after installing LG-TP450.INF:
o Zadig <http://zadig.akeo.ie/> <https://github.com/pbatard/libwdi/wiki/Zadig>
o libusbK <https://sourceforge.net/projects/libusbk/>

Unfortunately, I don't know which made LibMTP finally work:
o Replacing "LG Stylo 3 Plus" MTP with the libusb-generated "LG-TP450.inf"
o Then adding Zadig
o Then adding libusbK

After I did those three things & tested LibMTP commands, they all worked.

I don't know which of those three in sequence made LibMTP finally work on
Windows 10, where it's important to figure that out so that others can
follow in our footsteps - but where I have to move forward nonetheless.

Since my credibility is important, I prove what I say, where here are
screenshots proving the set of libmtp bin commands are finally working on
Windows 10 - providing a glimpse of the entire Android filesystem over USB:
o connect.exe <http://www.bild.me/bild.php?file=4656598libtmp01.jpg>
o files.exe <http://www.bild.me/bild.php?file=4184084libtmp02.jpg>
o folders.exe <http://www.bild.me/bild.php?file=8059960libtmp03.jpg>
o emptyfolders.exe <http://www.bild.me/bild.php?file=2119219libtmp04.jpg>
o detect.exe <http://www.bild.me/bild.php?file=4408040libtmp05.jpg>
o connect.exe <http://www.bild.me/bild.php?file=8349591libtmp06.jpg>
o tracks.exe <http://www.bild.me/bild.php?file=2378716libtmp07.jpg>
o (other commands) <http://www.bild.me/bild.php?file=8494912libtmp08.jpg>
(I wonder what "format.exe" does... :)

This empirical result leaves me with this critical question:
Q: What "can" we do with libMTP toward our goal of a general solution
(hence freeware) for mounting the Android MTP filesystem as a drive
letter on Windows over USB (so that all Windows commands work on it)?

[Dan Purgert]

Arlen Holder wrote:
> On Sat, 20 Oct 2018 03:15:47 -0000 (UTC), Arlen Holder wrote:
>
>> If I'm successful, this will be a first (to my knowledge) where almost
>> nobody knows how to do this, AFAIK, and where the power is immense
>> in that we can connect Android as a drive letter over USB using only
>> Windows freeware so that _all_ Windows commands run on the Android
>> filesystem.
>
> The goal is for _everyone_ to be able to run any Windows command on Android

Maybe post to a windows group then?

[William Unruh]

On 2018-10-20, Dan Purgert <d...@djph.net> wrote:
> Arlen Holder wrote:
>> On Sat, 20 Oct 2018 03:15:47 -0000 (UTC), Arlen Holder wrote:
>>
>>> If I'm successful, this will be a first (to my knowledge) where almost
>>> nobody knows how to do this, AFAIK, and where the power is immense
>>> in that we can connect Android as a drive letter over USB using only
>>> Windows freeware so that _all_ Windows commands run on the Android
>>> filesystem.
>>
>> The goal is for _everyone_ to be able to run any Windows command on Android

I think you will have to write new drivers then for Android. AFAIK, the
mtp filesystem does not allow arbitrary reading and writing of files.
It's purpose is to allow transfer of the data, not random read/writes.

[Carlos E.R.]

On 20/10/2018 18.13, Arlen Holder wrote:
> On Sat, 20 Oct 2018 03:15:47 -0000 (UTC), Arlen Holder wrote:
>
>> If I'm successful, this will be a first (to my knowledge) where almost
>> nobody knows how to do this, AFAIK, and where the power is immense
>> in that we can connect Android as a drive letter over USB using only
>> Windows freeware so that _all_ Windows commands run on the Android
>> filesystem.
>
> The goal is for _everyone_ to be able to run any Windows command on Android
> over USB,

Why would we be interested on doing that, as we use Linux?

--
Cheers, Carlos.

[R.Wieser]

Arlen,

> The goal is for _everyone_ to be able to run any Windows
> command on Android

I think you would do good to define - for yourself *and* us - what a
"windows command" is, as well as to come up with a list of "must haves"
(preferrably in order of importance). And I think (hope) you (just) ment
*filesystem* related commands there.

Furthermore, there are a few commands you will never be able to run on
android in any meaningfull way. Take "chkdsk" for example. Or "fdisk".
Or "Attrib".

Also, as William (Unruh) already mentioned, you do not seem to realize that
you can only do what the available interfaces/APIs offer you.

Regards,
Rudy Wieser

[Arlen Holder]

On Sun, 21 Oct 2018 15:45:08 +0200, R.Wieser wrote:

> Also, as William (Unruh) already mentioned, you do not seem to realize that
> you can only do what the available interfaces/APIs offer you.

I'm trying to advance what we _can_ do, where I admit freely that most of
you can do far more than I can do with both Windows & Linux interfacing
with Android.

All I ever ask is for you to help _improve_ our knowledge - or - to not
troll if you can't improve our knowledge. It's a binary decision to make.

Any post that doesn't _improve_ our capabilities, is just wasted chitchat.

As noted by William Unruh and others, when you plug an Android 4.3+ device
set up as MTP into Windows over USB, you can't run Windows commands
_directly_ on the Android filesystem.
<http://www.bild.me/bild.php?file=9648761dir.jpg>

Hence, the goal is for everyone to be able to run any Windows command on
the entire Android filesystem, over USB (because it's fast, secure, & easy)
& over WiFi (because it works over the local network).

I've experimented in the past couple of days about as far as I can go.
What we need from experts here is your added value to go further.

To that end, I summarize below where my knowledge falls off the cliff.
If you know more than I do, please improve these suggestions below.

*Goal: Run any Windows command directly on the Android filesystem.*
==========================================
*These worked perfectly in my tests (Android 7.0, Windows 10)*
==========================================
1. MTP over USB: (*MTPDrive*)
<http://www.bild.me/bild.php?file=1853998dir02.jpg>
o Android set to MTP + MTPDrive payware on Windows
o Mount the Android filesystem as a drive letter on Windows
o MTPDrive freeware is limited to 30 files transferred per session
<http://www.bild.me/bild.php?file=8315262dir03.jpg>
Tested with:
MTPDrive <http://mtpdrive.com/download.html>

2. MTP over USB: (*Linux*)
<http://www.bild.me/bild.php?file=6181360dir01.jpg>
o Android set to MTP + dual-boot Ubuntu with Windows
o There are no limits whatsoever as to what you can do
Tested with:
Ubuntu 18.04 <https://www.ubuntu.com/download/desktop>

3. WebDAV over WiFi: (*net use)
<http://www.bild.me/bild.php?file=8605173dir05.jpg>
o WebDAV freeware server on Android + "net use" on Windows
o Mount the Android filesystem as a drive letter on Windows
o There are no limits whatsoever as to what you can do
Tested with:
<https://play.google.com/store/apps/details?id=com.theolivetree.webdavserver>

4. FTP over WiFi: (*DirectNetDrive*)
<http://www.bild.me/bild.php?file=4731516dir011.jpg>
<http://www.bild.me/bild.php?file=6340420dir012.jpg>
o FTP freeware server on Android + DnD freeware on Windows
o Mount the Android filesystem as a drive letter using DnD freeware
o There are no limits whatsoever as to what you can do
Tested with:
DirectNetDrive <http://www.directnet-drive.net/>

5. FTP over WiFi: (*NetDrive 1.3.2.0*)
<http://www.bild.me/bild.php?file=1383190dir014.jpg>
o FTP freeware server on Android + (older) NetDrive freeware on Windows
o Mount the Android filesystem as a drive letter using NetDrive freeware
o There are no limits whatsoever as to what you can do
Tested with:
NetDrive 1.3.2.0 <https://filehippo.com/download_netdrive/12615/>

==========================================
*These worked to run commands - but we don't have a mounting solution.*
==========================================
6. MTP over USB: (*libMTP*, libusbK, libiconv)
<http://www.bild.me/bild.php?file=4656598libtmp01.jpg>
o Plug in Android to USB + libMTP commands on Windows
o Can see and manipulate every file on the Android filesystem
o But it can't yet mount the Android filesystem as a drive letter
Tested with:
LibMTP <https://sourceforge.net/projects/libmtp/>
LibusbK <https://sourceforge.net/projects/libusb-win32/>
LibiConv <http://gnuwin32.sourceforge.net/packages/libiconv.htm>

==========================================
*These failed miserably in my tests - but they may work for others.*
==========================================
7. FTP over WiFi: (*net use*)
<http://www.bild.me/bild.php?file=8734999ftpshare02.jpg>
o FTP server freeware on Android + "net use" on Windows
o Mount the Android filesystem as a drive letter on Windows
o I can't figure out the doublebackslash syntax to make it work!
Tested with:
<https://play.google.com/store/apps/details?id=com.theolivetree.ftpserver>

8. FTP over WiFi: (*FTPuse*)

<http://www.bild.me/bild.php?file=7687244dir06.jpg>
<http://www.bild.me/bild.php?file=7075400dir07.jpg>
<http://www.bild.me/bild.php?file=3316456dir08.jpg>

<http://www.bild.me/bild.php?file=7355568dir09.jpg>
<http://www.bild.me/bild.php?file=4223201dir010.jpg>
o FTP server freeware on Android + FTPuse freeware on Windows
o Mount the Android filesystem as a drive letter using FTPuse freeware
o There are no limits whatsoever as to what you can do
Tested with:
FTPUse <https://www.ferrobackup.com/download/FtpUseInst.exe>

9. FTP over WiFi: (*SFTPNetDrive*)\
<http://www.bild.me/bild.php?file=2809525dir013.jpg>
o FTP server freeware on Android + SFTPNetDrive freeware on Windows
o Mount the Android filesystem as a drive letter using SFTPNetDrive
o There are no limits whatsoever as to what you can do
Tested with:
SFTP Net Drive <https://www.nsoftware.com/sftp/netdrive/>

10. SMB over WiFi: (*net use*)
o SMB server freeware on Android + native Windows "net use"
o Main problem is Android needs to be rooted to use TCP port 445
o Second problem is finding Android SMB server non-root freeware
Tested with:
<https://play.google.com/store/apps/details?id=com.icecoldapps.sambaserver>

==========================================
*These were not tested because they are trialware solutions.*
==========================================
11. FTP or WebDAV over WiFi: (*WebDrive*)
o FTP/WebDAV freeware server on Android + WebDrive trialware on Windows
o Mount the Android filesystem as a drive letter using WebDrive trialware
o The trialware is limited to 10 days
Not tested:
WebDrive <https://webdrive.com/download/>

12. FTP over WiFi: (*NetDrive*)
o FTP freeware server on Android + (current) NetDrive trialware on Windows
o Mount the Android filesystem as a drive letter using NetDrive trialware
o There are no limits whatsoever as to what you can do
Not tested:
NetDrive 3.6.571 <http://netdrive.net/
==========================================

In summary, we need your added value to get past where I am above.

Above is where I fall off the cliff on trying to help everyone run any
Windows command directly on any Android 4.3+ filesystem over USB or WiFi.

As always, the goal is a universal solution for everyone.
If you can add value, please pitch in to improve our capabilities.
--
We are always far stronger together than any of us are all alone.

[R.Wieser]

Arlen,

> All I ever ask is for you to help _improve_ our knowledge - or -
> to not troll if you can't improve our knowledge. It's a binary decision
> to make.

Don't ask people here for for full solutions, especially not accompanied by
a vague "it must do *everything*" blurb. Its a simple binary decision to
make.

And ditch the "we". You are not part of the/any group providing knowledge,
you're the consumer of it.

Also, there are (still) people here wanting to help you *learn* something.
So that you can repeat it on your own, and extend on it. What you are
currently doing is not learning, and no matter what the people here give you
you won't *ever* be able to do it on your own.

As such I consider it an absolute waste of my time to contribute to it.
Its as simple as that.

Regards,
Rudy Wieser

[Carlos E.R.]

On 21/10/2018 20.29, Arlen Holder wrote:
> On Sun, 21 Oct 2018 15:45:08 +0200, R.Wieser wrote:
>
>> Also, as William (Unruh) already mentioned, you do not seem to realize that
>> you can only do what the available interfaces/APIs offer you.
>
> I'm trying to advance what we _can_ do, where I admit freely that most of
> you can do far more than I can do with both Windows & Linux interfacing
> with Android.
>
> All I ever ask is for you to help _improve_ our knowledge - or - to not
> troll if you can't improve our knowledge. It's a binary decision to make.
>
> Any post that doesn't _improve_ our capabilities, is just wasted chitchat.
>
> As noted by William Unruh and others, when you plug an Android 4.3+ device
> set up as MTP into Windows over USB, you can't run Windows commands
> _directly_ on the Android filesystem.
> <http://www.bild.me/bild.php?file=9648761dir.jpg>
>
> Hence, the goal is for everyone to be able to run any Windows command on
> the entire Android filesystem, over USB (because it's fast, secure, & easy)
> & over WiFi (because it works over the local network).

I stop reading here. You need to ask Windows people, not Linux people.
This is a *Linux* group.


--
Cheers, Carlos.

[R.Wieser]

Carlos,

> I stop reading here. You need to ask Windows people, not Linux
> people. This is a *Linux* group.

Good catch.

The final program should *ofcourse* run both on Windows (all versions) as
well as on "Linux" (all distributions, all versions). Duh!

And that Windows and Linux do not even give same output (because of
different available file info) ? Well, that is just something we - as in:
everyone but Arlen - should figure out ofcourse. He's the idea man, we
just have to fill in some minor details (like the whole program).

Easy, no ? Almost as easy as the "make awsome program" button I've got here
somewhere. :-)

Regards,
Rudy Wieser

[Arlen Holder]

On Sun, 21 Oct 2018 22:56:13 +0200, Carlos E.R. wrote:

> You need to ask Windows people, not Linux people.

Hi Carlos E.R.,
You are wholly correct, where I was just updating the thread, but, where
this will be my _last_ post to this thread, for the very reason you stated.

Since I never fail (almost never, unless it's actually impossible), I will
succeed (and have succeeded almost completely already) in running not only
any Linux command I want to on the Android file system, but also any
Windows command, over both USB and WiFi.

If anyone here wishes to be kept abreast of the progress, it will be here:
Tutorial to run any Windows command directly on Android over either USB or Wi-Fi
<https://groups.google.com/forum/#!topic/comp.mobile.android/JrWLPRYO-TU>

And, perhaps here (where Paul just now tried to lend a helping hand):
What's the best way to forward SMB TCP port 445 to something higher than 1024 on Windows?
<https://groups.google.com/forum/#!topic/comp.mobile.android/3QQ8bAZeXNI>

While this thread never should have been on a Linux group, in my defense,
you have to understand a few key points:
o 99% of all the articles on any technical thread, are utterly worthless
o For example anything from Dan Purget or Rudy Wieser is always worthless

It's likely that, in the entire history of all the posters to this
newsgroup, that only 1 to 5 of those posters has the technical capability
to solve the stated problems. Maybe 10 if we push it.

Which means there's from 0 to 1 person reading this very thread, who has
the technical skills to help answer the questions posed.

HINT: It's _never_ going to be Dan Purgert or Rudy Wieser, but it _could_
be one of the others who posted to this thread. Maybe. But probably not.

Since only 1 out of, oh, I don't know, 1000 people perhaps, has the skills
needed to answer the questions posed, these types of threads are best left
*empty* (i.e., devoid of worthless posts from the likes of Rudy Wieser or
Dan Purgert).

I don't fear silence. The pregnant pause is fine if nobody even
_comprehends_ the question.

What's a waste of time is not my original question - but the incesseant
drivel that people post that is utterly worthless.

Having said that, I'm fine with an empty thread with only a single solitary
question and no answer; hence, this is my last post to this thread since
you are completely correct that this is a Windows issue - since everything
works just fine on Linux.

This thread should never have been on the linux group in the first place.
I apologize.
It's not a Linux problem, & even if it was, it's beyond most people here.

[Dan Purgert]

Arlen Holder wrote:
> On Sun, 21 Oct 2018 15:45:08 +0200, R.Wieser wrote:
>
>> Also, as William (Unruh) already mentioned, you do not seem to realize that
>> you can only do what the available interfaces/APIs offer you.
>
> I'm trying to advance what we _can_ do, where I admit freely that most of

> you can do far more than I can do with both Windows [...]

Not in this NG though.

>
> All I ever ask is for you to help _improve_ our knowledge - or - to not

Like, maybe posting windows-related things to, I dunno, *.windows ?

>
> Any post that doesn't _improve_ our capabilities, is just wasted chitchat.

Like posting about windows to a Linux NG?

>
>
> Hence, the goal is for everyone to be able to run any Windows command on
> the entire Android filesystem, over USB (because it's fast, secure, &
> easy) & over WiFi (because it works over the local network).

Why would a group of people in a *Linux* newsgroup care about running
"Windows" commands, eh?

>
> I've experimented in the past couple of days about as far as I can go.
> What we need from experts here is your added value to go further.

Post to *.windows, not alt.os.linux.


> [...]

> In summary, we need your added value to get past where I am above.

Summary of the summary -> "Arlen doesn't know how to post to the right
NG."

[Dan Purgert]

R.Wieser wrote:
> Carlos,
>
>> I stop reading here. You need to ask Windows people, not Linux
>> people. This is a *Linux* group.
>
> Good catch.
>
>

> Easy, no ? Almost as easy as the "make awsome program" button I've
> got here somewhere. :-)

I'll lend you mine. Note it just prints 1MB of /dev/urandom.

Hasn't failed me yet!

[Dan Purgert]

Arlen Holder wrote:
> On Sun, 21 Oct 2018 22:56:13 +0200, Carlos E.R. wrote:
>
>> You need to ask Windows people, not Linux people.
>

> It's not a Linux problem, & even if it was, it's beyond most people here.

Hi Arlen H. Holder,

Nice insult to the group there ...

[Carlos E. R.]

On 22/10/2018 11.23, Dan Purgert wrote:
> Arlen Holder wrote:
>> On Sun, 21 Oct 2018 15:45:08 +0200, R.Wieser wrote:
>>
>>> Also, as William (Unruh) already mentioned, you do not seem to realize that
>>> you can only do what the available interfaces/APIs offer you.
>>
>> I'm trying to advance what we _can_ do, where I admit freely that most of
>> you can do far more than I can do with both Windows [...]
>
> Not in this NG though.
>
>>
>> All I ever ask is for you to help _improve_ our knowledge - or - to not
>
> Like, maybe posting windows-related things to, I dunno, *.windows ?

Right :-)

While it is possible that many of us also use Windows and know a bit
about both systems, I at least am not inclined to answer questions that
only relate to Windows here. I have no issues with interoperability
questions, though. This was not one.


--
Cheers,
Carlos E.R.

[R.Wieser]

Dan,

> Like, maybe posting windows-related things to, I dunno, *.windows ?

He did. But people there are starting to ignore, or even activily
rejecting him (like me). So, he needs a new batch of
suckers^wwilling-to-help people to deliver programs to him that will exactly
do as he requests.

As for the insulting ? Yep, thats his style. Probably an attempt to get
you riled up and wanting to prove that you aren't - and by it giving him
exactly what he wants ofcourse.

>> Easy, no ? Almost as easy as the "make awsome program" button I've
>> got here somewhere. :-)
>
>I'll lend you mine. Note it just prints 1MB of /dev/urandom.
>
>Hasn't failed me yet!

Well, thats both cheaper and faster than "a thousand monkeys on a thousand
typewriters, banging them for a thousand etherneties". :-)

Regards,
Rudy Wieser

[RonB]

You really need to get over yourself, Arlen. I'm sure there are folks here
who DO have the technical skills to answer whatever question it was your
asking between all the pontificating. They just don't care. And, with all
due respect, this is NOT a programming newsgroup, it's a Linux newsgroup. I
don't know a thing about programming. Not ashamed about that at all. I come
here because the newsgroup is about LINUX.

Good luck with whatever it is you're doing.

--
The more I see of Windows, the more I like Linux.

[RonB]

On 2018-10-22, Dan Purgert <d...@djph.net> wrote:
> Arlen Holder wrote:
>> On Sun, 21 Oct 2018 22:56:13 +0200, Carlos E.R. wrote:
>>
>>> You need to ask Windows people, not Linux people.
>>
>> It's not a Linux problem, & even if it was, it's beyond most people here.
>
> Hi Arlen H. Holder,
>
> Nice insult to the group there ...

It would have been better if had been more succinct and he had he not gone
the Nixon route of ... "you won't me to kick around any more."

What was it he was trying to do, emulate inferior Windows commands in
Android? Why?

[Carlos E. R.]

On 23/10/2018 02.47, RonB wrote:
> On 2018-10-21, Arlen Holder <a%rlenh...@no.spam.net> wrote:
>> On Sun, 21 Oct 2018 22:56:13 +0200, Carlos E.R. wrote:
>>
>>> You need to ask Windows people, not Linux people.
>>
>> Hi Carlos E.R.,
>> You are wholly correct, where I was just updating the thread, but, where
>> this will be my _last_ post to this thread, for the very reason you stated.
>>
>> Since I never fail (almost never, unless it's actually impossible), I will
>> succeed (and have succeeded almost completely already) in running not only
>> any Linux command I want to on the Android file system, but also any
>> Windows command, over both USB and WiFi.

...

>> Having said that, I'm fine with an empty thread with only a single solitary
>> question and no answer; hence, this is my last post to this thread since
>> you are completely correct that this is a Windows issue - since everything
>> works just fine on Linux.
>>
>> This thread should never have been on the linux group in the first place.
>> I apologize.
>> It's not a Linux problem, & even if it was, it's beyond most people here.
>
> You really need to get over yourself, Arlen. I'm sure there are folks here
> who DO have the technical skills to answer whatever question it was your
> asking between all the pontificating. They just don't care.

Indeed.

The moment he starts with insults and pontifications, I stop reading.

> And, with all
> due respect, this is NOT a programming newsgroup, it's a Linux newsgroup. I
> don't know a thing about programming. Not ashamed about that at all. I come
> here because the newsgroup is about LINUX.
>
> Good luck with whatever it is you're doing.
>


--

Cheers,
Carlos E.R.

[Arlen_Holder]

On Fri, 12 Oct 2018 15:43:51 -0000 (UTC), Arlen Holder wrote:

> The question for this ng is how to run a command from Ubuntu 18.04 on the
> Android file system plugged into the desktop USB port as an MTP device?

Purely for the tribal record (for others to find in the future when asking
similar questions), here's a summary that I had posted to the Windows &
Android ngs which summarizes that the only universal solution (i.e., purely
native solution) was to use Ubuntu 18.04 as a dual-boot with Windows.

==== cut here for the final summary ====
As a possible solution, the only method that worked over USB was MTPDrive:
<https://groups.google.com/forum/#!topic/alt.comp.freeware/TaIlIMK2Nuw%5B1-25%5D>

Unfortunately, MTPDrive is crippleware, where it's pretty much definite
that there is no Windows freeware extant that will mount the Android
internal or external SD card contents over USB as a drive letter.

The closest we can find, together, even with our immense tribal experience,
is the long-known MTPDrive crippleware, which we all knew about _before_ we
started this quest for a freeware replacement to MTPDrive functionality
(and which has 4 critical functionality flaws which negate MTPDrive as a
general solution for everyone - which is _always_ the goal).

To add further value to the overall tribal knowledge, I have found yet
another limitation of the MTPDrive crippleware, which I encountered, just
now, when I happened to have both the Android & iOS devices connected by
USB on Windows.

I was copying over this morning the APK of my first Android app I created:
<https://groups.google.com/forum/#!topic/alt.comp.freeware/qEqThtRwZAg>
When this new-to-me error popped up:
"MTPDrive - Error
Trial version limit reached:
-> Maximum number of mapped devices = 1"

Here is a screenshot showing the attempt to map both Android & iOS on Win:
<http://www.bild.me/bild.php?file=2725206dir028.jpg>

In my experience, these are the 4 limitations of the MTPDrive crippleware:
o Only 1 mobile device can be mounted per session
o Only 30 files can be copied per session
o On the _external_ sdcard seemed to be mountable (not internal storage)
o The Dokan Library used by MTPDrive & FTPUse are apparently incompatible
<http://www.bild.me/bild.php?file=8315262dir03.jpg

Otherwise, MTPDrive crippleware works perfectly on Windows to mount the
Android internal and external sd card contents over USB as a drive letter.

In summary, nobody on any of these newsgroups knows of any working general
solution to the problem of mounting the Android internal and external
storage as a drive letter on Windows over USB such that all Windows
commands work:
<http://www.bild.me/bild.php?file=1853998dir02.jpg>

The best Windows solution is to mount Android as a drive letter over WiFi:
o WebDAV <http://www.bild.me/bild.php?file=8605173dir05.jpg>
o DirectNetDrive <http://www.bild.me/bild.php?file=6340420dir012.jpg>
o NetDrive v1.3.2.0 <http://www.bild.me/bild.php?file=1383190dir014.jpg>
o webdav <http://www.bild.me/bild.php?file=2373390dir019.jpg>
o netdrive <http://www.bild.me/bild.php?file=3994244dir020.jpg>

Although plenty of those solutions failed miserably in my tests:
o FTPuse <http://www.bild.me/bild.php?file=7687244dir06.jpg>
o FTPuse <http://www.bild.me/bild.php?file=3316456dir08.jpg>
o FTPuse <http://www.bild.me/bild.php?file=4223201dir010.jpg>
o SFTP Net Drive <http://www.bild.me/bild.php?file=2809525dir013.jpg>
o netuseloginport <http://www.bild.me/bild.php?file=8381514dir017.jpg>
o netuseloginport <http://www.bild.me/bild.php?file=3626731dir018.jpg>
o ftp netuse fails <http://www.bild.me/bild.php?file=4233679dir018.jpg>
o ftpuse works <http://www.bild.me/bild.php?file=4121239dir021.jpg>
o ftpuse fails <http://www.bild.me/bild.php?file=5451129dir022.jpg>
o ftpuse fails <http://www.bild.me/bild.php?file=8726712dir023.jpg>
o fptuse firewall <http://www.bild.me/bild.php?file=9234464dir024.jjpg.jpg>
o ftpdrive <http://www.bild.me/bild.php?file=4023721dir025.jjpg.jpg>

The best solution, overall, since it requires no non-native software
anywhere, is to use a dual-boot Ubuntu 18.04, which can simultaneously
read/write not only the entire visible Android filesystem over USB, but
also it has read/write access to the entire visible Windows (yes, even as a
dual boot, as long as Windows hibernation is off), Linux, & iOS file
systems:
<http://www.bild.me/bild.php?file=6181360dir01.jpg>
==== cut here for the final summary ====

[Kenny McCormack]

In article <g38d9h...@mid.individual.net>,
Carlos E. R. <robin_...@es.invalid> wrote:
...
>>care. the the there yourself, it to really just DO here between get
>>technical sure pontificating. question are Arlen. was answer need
>>don't have all over skills You They who folks I'm asking your whatever to

>
>Indeed.
>
>The moment he starts with insults and pontifications, I stop reading.

You need to realize that that is exactly the goal. Your posts (certainly
on this thread, if not in general and globally) are, to put it as
charitably as possible, idle chitchat. They have no value.

They serve no purpose other than to stroke your ego, and Arlen is quite
right to say that silence would have been preferable to your having posted.
In short, you would have done much better had you stopped posting to this
thread one post sooner.

The goal of Arlen's insults is precisely to get the worthless posters to
stop posting to the thread. As I say, that is exactly the goal.

--
The people who were, are, and always will be, wrong about everything, are still
calling *us* "libtards"...

(John Fugelsang)

[Carlos E. R.]

On 09/05/2019 17.40, Kenny McCormack wrote:
> In article <g38d9h...@mid.individual.net>,
> Carlos E. R. <robin_...@es.invalid> wrote:
> ...
>>> care. the the there yourself, it to really just DO here between get
>>> technical sure pontificating. question are Arlen. was answer need
>>> don't have all over skills You They who folks I'm asking your whatever to
>>
>> Indeed.
>>
>> The moment he starts with insults and pontifications, I stop reading.
>
> You need to realize that that is exactly the goal. Your posts (certainly
> on this thread, if not in general and globally) are, to put it as
> charitably as possible, idle chitchat. They have no value.
>
> They serve no purpose other than to stroke your ego, and Arlen is quite
> right to say that silence would have been preferable to your having posted.
> In short, you would have done much better had you stopped posting to this
> thread one post sooner.
>
> The goal of Arlen's insults is precisely to get the worthless posters to
> stop posting to the thread. As I say, that is exactly the goal.

And your goal, posting this 198 days later, saves some purpose aside
from insulting me?

--
Cheers,
Carlos E.R.